Low-latency, outbound message monitoring, control, and authentication

ABSTRACT

Embodiments of the present disclosure provide a first set of methods, computer-readable media, and system configured for: receiving a configuration for a domain name system (DNS) to log all queries; publishing a customized sender policy framework (SPF) policy to the DNS, the customized SPF policy comprising a macro-endowed mechanism; logging a plurality of received SPF customized queries; accessing a log comprising the plurality of received SPF customized queries; extracting data from each of the received SPF customized queries, the data being populated by the macro mechanism associated with the SPF customized query; populating a datastore with extracted data comprising at least one of the following: a username, a IP address, and a domain, as extracted from each received SPF customized query; and providing, based on the extracted data, an indication of outbound emails sent from the domain. In various embodiments, email authorizations and restrictions may be based thereon.

RELATED APPLICATIONS

Under provisions of 35 U.S.C. § 119(e), Applicant claims the benefit ofU.S. Provisional Application No. 62/895,638 filed Sep. 4, 2019 and U.S.Provisional Application No. 62/893,526 filed Aug. 29, 2019. Thedisclosures of each of the aforementioned applications are herebyincorporated by reference.

FIELD OF DISCLOSURE

It is intended that each of the referenced applications may beapplicable to the concepts and embodiments disclosed herein, even ifsuch concepts and embodiments are disclosed in the referencedapplications with different limitations and configurations and describedusing different examples and terminology. The present disclosure relatesto system security and data transfers, and more specifically, toproviding communication data, third-party email service providerauthorization, and user-level outbound message control toadministrators.

BACKGROUND

There are a number of different entities that may send email on behalfof a particular domain. For example, a company employee, an independentmarketing representative, and a third-party marketing agency may allsend email using the domain of the company. It is desirable foradministrators to gather more data and have more control regarding theemails sent from a domain.

Electronic mail or email is a ubiquitous tool used by organizations forinternal and external messaging. Legitimate users of an organization'semail identity can include employees, contractors, and vendors. Also,third-party agencies can be configured to send email on behalf of theorganization in order to fulfill service roles such as marketing andonline document signature management.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)and Sender Policy Framework (SPF), the validation process performed bythe message receiver's email service provider can, through the use ofthese authentication protocols, forward information about the nominalsender to the domain of the sender immediately. Through regularchannels, DMARC reports can take 24 hours or more to become available toa domain manager.

There has been no generally-available way for administrators to haveimmediate visibility into the volume of messages sent by specific usersof a domain's email identity. The ability to determine message sendingvolume broken-down by individuals and third-party services would provideresource and security managers with the intelligence to better allocateassets and establish sending patterns that would be useful for detectingfraud and abuse.

SUMMARY

This brief overview is provided to introduce a selection of concepts ina simplified form that are further described below in the DetailedDescription. This brief overview is not intended to identify keyfeatures or essential features of the claimed subject matter. Nor isthis brief overview intended to be used to limit the claimed subjectmatter's scope.

Embodiments of the present disclosure provide a first set of methods,computer-readable media, and system configured to perform the followingstages:

receiving a configuration for a domain name system (DNS) to log allqueries;

publishing a customized sender policy framework (SPF) policy to the DNS,the customized SPF policy comprising a macro-endowed mechanism forobtaining at least one of the following:

a username,

an IP address, and

a domain;

logging a plurality of received SPF customized queries;

accessing a log comprising the plurality of received SPF customizedqueries; extracting data from each of the received SPF customizedqueries, the data being populated by the macro mechanism associated withthe SPF customized query;

populating a datastore with extracted data comprising at least one ofthe following: the username, the IP address, and the domain, asextracted from each received SPF customized query; and

providing, based on the extracted data, an indication of outbound emailssent from the domain.

Embodiments of the present disclosure provide a second set of methods,computer-readable media, and system configured to perform the followingstages:

publish a customized sender policy framework (SPF) policy to the DNS,the customized SPF policy comprising a macro-endowed mechanism forobtaining at least one of the following:

a username,

an IP address, and

a domain;

log a plurality of received SPF customized queries;

access a log comprising the plurality of received SPF customizedqueries;

extract data from each of the received SPF customized queries, the databeing populated by the macro mechanism associated with the SPFcustomized query;

populate the memory with extracted data comprising at least one of thefollowing: the username, the IP address, and the domain, as extractedfrom each received SPF customized query; and

organize a display of the extracted data, the display being configuredto provide an indication of outbound emails sent from the domain.

Embodiments of the present disclosure provide a third set of methods,computer-readable media, and system configured to perform the followingstages:

enable a configuration of individual user authorizations to allowoutbound messaging through a specification of one or more authorizedvendors;

withhold from publication to the DNS at least one DKIM public keyassociated with the one or more authorized vendors;

publish a customized sender policy framework (SPF) policy to the DNS,the customized SPF policy comprising a macro-endowed mechanism forobtaining at least one of the following:

a username,

an IP address, and

a domain;

logging a received SPF customized queries;

accessing a log comprising the received SPF customized queries;

extract data from the received SPF customized queries, the extracteddata having been populated by the macro mechanism associated with theSPF customized query;

analyze the extracted data comprising at least one of the following: theusername, the IP address, and the domain, as extracted from eachreceived SPF customized query;

determine whether an individual associated with the username isauthorized to utilize a vendor associated with the domain;

publish, upon a determination that the individual is authorized toutilize the vendor, a DKIM public key associated with the vendor.

Embodiments of the present disclosure provide a fourth set of methods,computer-readable media, and system configured to perform the followingstages: receiving a configuration individual user authorizations forallowing outbound messaging through a specification of one or moreauthorized vendors;

publishing a customized sender policy framework (SPF) policy to the DNS,the customized SPF policy comprising a macro-endowed mechanism forobtaining at least one of the following:

a username,

an IP address, and

a domain;

logging a received SPF customized queries;

accessing a log comprising the received SPF customized queries;

extracting data from the received SPF customized queries, the extracteddata having been populated by the macro mechanism associated with theSPF customized query;

analyzing the extracted data comprising at least one of the following:the username, the IP address, and the domain, as extracted from eachreceived SPF customized query; and

determining whether an individual associated with the username isauthorized to utilize a vendor associated with the domain;

performing, upon a determination that the individual is authorized toutilize the vendor, a function to authorize the outbound messaging,wherein performing the function to authorize the outbound messagingcomprises informing at least one function running a domain name system(DNS) so that an appropriate qualifier can be returned to for SPFverification.

Embodiments of the present disclosure provide a fifth set of methods,computer-readable media, and system configured to perform the followingstages: receiving a configuration of individual user authorizations forallowing outbound messaging through a specification of one or moreauthorized vendors;

publishing a customized sender policy framework (SPF) policy to the DNS,the customized SPF policy comprising a macro-endowed mechanism forobtaining at least one of the following:

a username,

an IP address, and

a domain;

logging a received SPF customized queries;

accessing a log comprising the received SPF customized queries;

extracting data from the received SPF customized queries, the extracteddata having been populated by the macro mechanism associated with theSPF customized query;

analyzing the extracted data comprising at least one of the following:the username, the IP address, and the domain, as extracted from eachreceived SPF customized query;

determining whether an individual associated with the username isauthorized to utilize a vendor associated with the domain;

performing, upon a determination that the individual is authorized toutilize the vendor, a function to authorize the outbound messaging.wherein performing the function to authorize the outbound messagingcomprises providing an affirmative response to an authentication requestin accordance with a corresponding messaging protocol utilized, at leastin part, to perform a message request.

Both the foregoing brief overview and the following detailed descriptionprovide examples and are explanatory only. Accordingly, the foregoingbrief overview and the following detailed description should not beconsidered to be restrictive. Further, features or variations may beprovided in addition to those set forth herein. For example, embodimentsmay be directed to various feature combinations and sub-combinationsdescribed in the detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this disclosure, illustrate various embodiments of the presentdisclosure. The drawings contain representations of various trademarksand copyrights owned by the Applicant. In addition, the drawings maycontain other marks owned by third parties and are being used forillustrative purposes only. All rights to various trademarks andcopyrights represented herein, except those belonging to theirrespective owners, are vested in and the property of the Applicant. TheApplicant retains and reserves all rights in its trademarks andcopyrights included herein, and grants permission to reproduce thematerial only in connection with reproduction of the granted patent andfor no other purpose.

Furthermore, the drawings may contain text or captions that may explaincertain embodiments of the present disclosure. This text is included forillustrative, non-limiting, explanatory purposes of certain embodimentsdetailed in the present disclosure. In the drawings:

FIG. 1 illustrates an example of a block diagram of a messageauthorization flow.

FIGS. 2 and 3 illustrate a block diagram of an example embodiment of aflow of data sent in a message volume monitoring system.

FIG. 4 illustrates a block diagram of an example method for performingthe methods described.

FIG. 5 illustrates a user interface.

FIG. 6 illustrates another user interface.

FIG. 7 illustrates a block diagram of an example method for performingauthorization of email account holders to use external email serviceproviders.

FIGS. 8 and 9 illustrate a block diagram of an example method forperforming authorization of email account holders.

FIG. 10 illustrates a block diagram of a method for performingauthorization of email account holders.

FIG. 11 illustrates an example of a configuration file.

FIG. 12 illustrates an example user interface for managing vendoraccess.

FIG. 13 illustrates a computing device compatible with the variousembodiments of the present disclosure.

DETAILED DESCRIPTION

As a preliminary matter, it will readily be understood by one havingordinary skill in the relevant art that the present disclosure has broadutility and application. As should be understood, any embodiment mayincorporate only one or a plurality of the above-disclosed aspects ofthe disclosure and may further incorporate only one or a plurality ofthe above-disclosed features. Furthermore, any embodiment discussed andidentified as being “preferred” is considered to be part of a best modecontemplated for carrying out the embodiments of the present disclosure.Other embodiments also may be discussed for additional illustrativepurposes in providing a full and enabling disclosure. Moreover, manyembodiments, such as adaptations, variations, modifications, andequivalent arrangements, will be implicitly disclosed by the embodimentsdescribed herein and fall within the scope of the present disclosure.

Accordingly, while embodiments are described herein in detail inrelation to one or more embodiments, it is to be understood that thisdisclosure is illustrative and exemplary of the present disclosure andare made merely for the purposes of providing a full and enablingdisclosure. The detailed disclosure herein of one or more embodiments isnot intended, nor is to be construed, to limit the scope of patentprotection afforded in any claim of a patent issuing here from, whichscope is to be defined by the claims and the equivalents thereof. It isnot intended that the scope of patent protection be defined by readinginto any claim a limitation found herein that does not explicitly appearin the claim itself.

Thus, for example, any sequence(s) and/or temporal order of steps ofvarious processes or methods that are described herein are illustrativeand not restrictive. Accordingly, it should be understood that, althoughsteps of various processes or methods may be shown and described asbeing in a sequence or temporal order, the steps of any such processesor methods are not limited to being carried out in any particularsequence or order, absent an indication otherwise. Indeed, the steps insuch processes or methods generally may be carried out in variousdifferent sequences and orders while still falling within the scope ofthe present disclosure. Accordingly, it is intended that the scope ofpatent protection is to be defined by the issued claim(s) rather thanthe description set forth herein.

Additionally, it is important to note that each term used herein refersto that which an ordinary artisan would understand such term to meanbased on the contextual use of such term herein. To the extent that themeaning of a term used herein—as understood by the ordinary artisanbased on the contextual use of such term—differs in any way from anyparticular dictionary definition of such term, it is intended that themeaning of the term as understood by the ordinary artisan shouldprevail.

Regarding applicability of 35 U.S.C. § 112, ¶6, no claim element isintended to be read in accordance with this statutory provision unlessthe explicit phrase “means for” or “step for” is actually used in suchclaim element, whereupon this statutory provision is intended to applyin the interpretation of such claim element.

Furthermore, it is important to note that, as used herein, “a” and “an”each generally denotes “at least one,” but does not exclude a pluralityunless the contextual use dictates otherwise. When used herein to join alist of items, “or” denotes “at least one of the items,” but does notexclude a plurality of items of the list. Finally, when used herein tojoin a list of items, “and” denotes “all of the items of the list.”

The following detailed description refers to the accompanying drawings.Wherever possible, the same reference numbers are used in the drawingsand the following description to refer to the same or similar elements.While many embodiments of the disclosure may be described,modifications, adaptations, and other implementations are possible. Forexample, substitutions, additions, or modifications may be made to theelements illustrated in the drawings, and the methods described hereinmay be modified by substituting, reordering, or adding stages to thedisclosed methods. Accordingly, the following detailed description doesnot limit the disclosure. Instead, the proper scope of the disclosure isdefined by the appended claims. The present disclosure contains headers.It should be understood that these headers are used as references andare not to be construed as limiting upon the subject matter disclosedunder the header.

Many electronic messaging technologies do not provide administratorsinformation about outbound messages from a domain or multiple domains. Adomain administrator may not be aware of outbound message sendingvolumes or patterns. Such electronic messaging technologies also fail toprovide administrators with an ability to, for example, authorizemessaging account holders to use external messaging service providers.

Gaining real-time intelligence about the sending behavior of individualaccounts would provide more-immediate insights into security compromisesand how to better allocate and secure sending resources. For example,some authorized users may typically send relatively few emails in thecourse of a day, while others may legitimately be associated with highvolume sending bursts, e.g., marketing service agents. An unusual spikein the message volume sent from a low-usage account could be anindicator of a security breach or a mere change of user role within theorganization. In the event of unauthorized usage, having immediateknowledge of such events allows a security manager to quickly interveneand take appropriate actions earlier in the process than would bepossible with conventional means which could be days or weeks after thedamage has been done.

Accordingly, the information about the nature and volume of sentmessages provides a system administrator (e.g., a user of the methodsand systems disclosed herein) with data associated with, for example,the sending of messages from an individual account. Embodiments of thepresent disclosure may provide such information without delay uponmessage receipt and authentication through methods and systems that canbe utilized by the system administrator to gain, by way of non-limitingexample, intelligence about sending patterns of those who send messageson behalf of the domain.

Such information may be valuable to identify, for example, how toimprove the performance of the system. This may, in turn, enable theuser to, for example, allocate resources according to the demands of theuser. Further still, this information may also be used to identify arise in sent messages from a particular account and investigate theaccount to identify, for example, a potential security failure.

The embodiments described herein may provide a user such as, forexample, an administrator to collect data about email sent by domainusers on behalf of the domain, such as, but not limited to, sendingvolume for individual users. As will be disclosed herein, thiscapability may be provided by, at least in part, using messageauthentication domain name system (DNS) queries.

Further still, embodiments described herein may provide methods andsystems to enable an administrator to control, such as, but not limitedto, perform restriction and authorization functionality. Saidfunctionality may be used in, for example, but not limited to,permitting certain email account holders to use external mail serviceproviders while restricting others. As will be disclosed herein, thiscapability may be performed in the various embodiments described hereinusing, at least in part, message authentication DNS queries. In theseways, embodiments of the present disclosure may provide a systemadministrator with faster insight and increased control of its users'out-bound email actions, thereby leading to a more regulated, secure andbetter performing system.

Still consistent with embodiments of the present disclosure, employingthe methods and systems described herein, a system administrator may beenabled to view outgoing message data, such as, but not limited to, thevolume of email sent by individual users on-demand. This may, in turnenable the administrator to more quickly identify potentially maliciousactivity in the system.

Further, various embodiments disclosed herein may allow the systemadministrator to take action based on a reading of the outgoing messagedata. For instance, in some embodiments, the system administrator may beenabled to tabulate email user accounts by sent message counts to betterallocate messaging resources, which improves the operation of the systemby improving the efficient use of resources. Such an efficient use ofresources may reduce the message sending volume of the system therebymaking the system run more cost effectively and, in some instances,faster for certain tasks. It should be understood that tabulation, forinstance, is only one potential use case of the methods and systemsdisclosed herein.

In yet further embodiments, the system administrator may be enabled tocontrol messaging permissions on a user level. For instance, the systemadministrator may be enabled to allow a first user to use an externalmessaging service provider while restricting a second user from usingthe same external messaging service provider. In accordance to thevarious embodiments disclosed herein, such functionality may beperformed using, at least in part, DNS controls and/or, in someembodiments, the DMARC, SPF and DKIM protocol controls. By way ofcontrast, in conventional systems, such control may not be readilyavailable to the system administrator through the domain controls on thesender-domain side alone, but rather take cooperation between thesender-domain and the external messaging server provider.

There are two important features of the SPF protocol that may beutilized for the various embodiments disclosed herein: i) a macrocharacter sequences, and ii) an SPF mechanism, such as, but not limitedto, the ‘exists’ term, a term is either a mechanism or a modifier, suchas, but not limited to, ‘redirect’ modifier that accepts macros, many ofthe mechanisms that may accept macros (‘a’, ‘include’, ‘exists’, ‘mx’),and others.

An SPF macro is a sequence of characters that, upon evaluation, arereplaced with key message parameters. Examples of such messageparameters include the source IP, the local-part of the sender, and thedomain in the ‘From’ address. According to the SPF specification, oneexample term, such as the ‘exists’ term, is a sender mechanism foridentifying IP addresses that either are permitted or are not permittedto use a domain's email identity. In accordance to various embodimentsherein, combining the ‘exists’ mechanism with particular macro sequenceswill facilitate a method to account for an email being sent by aspecific user in a nearly immediate way.

Consistent with the embodiments of the present disclosure,implementation may be achieved by, for example, the following stages: i)configuration of a DNS for authorizing domain to log all queries; ii)publication a specially-crafted SPF policy; and iii) extraction ofinformation from the DNS query. The stages will be detailed throughoutthe present disclosure, in various embodiments.

Under the various schemes disclosed herein, the response of the querycould be, by way of non-limiting example, ‘NXDOMAIN’ or ‘Name error’,meaning that the queried domain name does not exist in the DNS. Such aresponse may not be relevant or limit the functionality of the variousembodiments herein. Rather, the intended functionality of such queriesis to enable a subsequent extraction of data (e.g., the replacement ofthe macro terms contained within the actual query string). It should beunderstood that subsequent SPF policy and queries, that may returnmatching entries, can continue to function as intended and may not beimpeded by the introduction of the SPF queries of the presentdisclosure.

Accordingly, in some embodiments, in order to best-ensure that a DNSquery may be generated with appropriate sender information, an SPFpolicy may have the first term as a macro-endowed SPF term. By way ofnon-limiting example, an ‘exists’ mechanism may be employed. Alternativeterms and mechanisms that may be used by a custom SPF policy areprovided herein. With reference to the example “exists” mechanism, itmay be configured to specify a domain name to use in a DNS A-recordquery during the SPF authentication process. When combined with thespecial SPF macro character sequences as described herein, the name ofthe domain to be queried can be constructed from a variety of messageproperties, including the sender's email address, IP, and thecorresponding domain of the outbound server.

Still consistent with embodiments of the present disclosure, since aquery resulting from such SPF policy may correspond to a non-existentdomain, the result of this query could be ‘NXDOMAIN’ as describedearlier. Furthermore, the desired information about the sent email iscontained in the query string itself, and would be logged with the DNS.Thus, when this DNS query is made, the DNS logging system records thequery into a log file. And, by virtue of, at least in part, the macroterms users, preceding each of the fields may be a unique string todemarcate each piece of information in the query. One of ordinary skillin the field of the present disclosure may employ various techniques andstrategies for demarcating and/or extracting each information field.

Still consistent with embodiments of the present disclosure, the datathat allows tracking of user-resolved email sending volume may be keptin a data store separate from the DNS query logs. Updates to this datamay be pulled from the DNS query logs in an automated way, e.g., usingtimed scripts or triggered by some other means.

As an example, the data could be stored in a relational database with atable that contains fields corresponding captured by the macros alongwith a query timestamp, IP of the resolver used, or any other metadatathat may be present in the query that is of interest.

In yet further embodiments, an Application Programming Interface (API)to this data store may be implemented. In this way, a user interface maybe provided that is adapted to the system administrator's course ofoperations. The functions in the API perform the basic functions ofquerying the data store for specific contents. For example, to see allof the sending volume for a specific user, a query to filter results toinclude only results that label the user as the sender would be used. Inturn, the results of this query could be ingested into an administratorinterface that makes plain the amount of sent mail broken down byindividual users, marketing accounts, etc.

Further still, in some embodiments, by using metadata from the DNS querydata and other IP intelligence sources, information about a user's sentemail can be supplemented with other valuable insights such asgeographical location of the sending server and resolving IP.

Having access to such data may enable the system administrator toconfigure various control means. For instance, some embodiments of thepresent disclosure may enable the system administrator to constructlogic that may selectively authorize specific users for permission touse specific vendors. The vendors may provide, for example, emailforwarding services.

This may be achieved by enabling the administrator to set policies basedon data extracted from the DNS query log. There may be a plurality ofmethods and systems the administors may impose such restrictions (e.g.,it could be anticipated that protocols in current development or futuredevelopment may rely on certain aspects of the present disclosure toachieve the desired results and, therefore, are contemplated with thescope of applicable methods and systems used in conjunction with thepresent disclosure). The present disclosure provides a few methods andsystems for illustrative purposes.

In one aspect, a system may be configured to publish DKIM public keysupon a determination that both a user and an IP address, as extractedfrom the DNS query data, are approved for email communication.Accordingly, at the organizational level, the system administrator mayconfigure individual user authorizations on a per-vendor basis. In someembodiments, the system administrator may further opt to hold but not topublish each vendor's DKIM public key to their DNS. In yet otherembodiments, alternative means to publish DKIM public keys may beemployed. In turn, when the extracted DKIM query data is processed, itmay be determined that an authorized user using an IP associated with anauthorized vendor may send an email message, the DNS may be configuredto publish, with a short TTL, the DKIM public key associated with thecorresponding vendor. That is, in various embodiments, the DKIM publickey associated with the corresponding vendor may be temporarilypublished for enough duration to allow the message to undergo DKIMverification.

In another aspect, embodiments of the present disclosure may employbackend processing of authorization checks (e.g., vendor, user, IP—asone example referred to in FIG. 9.) can inform functions running on theDNS server so that an appropriate qualifier (e.g., pass, fail,soft-fail, neutral) can be returned to an external SPF verifier. In someembodiments, both aspects may be employed in whole or in part.

Still consistent with embodiments of the present disclosure, other logicmay be constructed in order to allow the aforementioned user and vendorlevel control. For example, the construction of subsequent SPF queriesof the SPF processing to trigger a match may be provided and enable suchauthentication on demand. Such process can be performed by, for example,the DNS server and/or various computing elements and software modulesoperating in conjunction therewith. This may be accomplished by, forexample, returning a value of ‘pass’ or ‘fail’ to the SPF verifieraccording to the results of the desired set of permission checks (user,vendor, IP, etc.). It should be understood that the stages disclosed tobe performed with reference to the DNS operations, even though they maybe disclosed to be performed under various labels and computingelements, may be combined into a single stage, or dispersed further intoyet additional stages, performed by the same or separate computingelements. It is, therefore, intended that the disclosed stages andcomputing elements are an abstraction that one of ordinary skill in thefield of the present disclosure could use to enable variousconfigurations contemplated to be within the spirit and scope of thepresent disclosure.

Throughout the various embodiments disclosed herein, security measuresmay be considered. In one instance, since SPF policies are published inpublic-viewable DNS records, it would be simple for an adversary to usethe above-described ‘exists’ mechanism term against a domain by floodingtheir DNS log files with many queries that imitate legitimate SPFlookups. For example, one merely needs to automate many DNS A-recordqueries directly to the following name:

_i.209.XXXXX41._o.example.com._d.example.com._l.joe._h.google.com.example.com

If such queries were directed at the domain, perhaps with varying fieldswith fake IPs and domains, then the data becomes corrupted and thesender statistics become unreliable.

One method to validate DNS log data is to ensure that an organizationaldomain associated with the IP address of the querying agent matches theorganizational domain of the IP field in the query. For example, supposethat the query above is performed from the IP2400:cb00:27:1024::ac45:ec23. This latter IP is associated with aCloudflare DNS while the IP in the query name is 209.XX.XXX.41 which isassociated with Google. Since these two organizations are not consistentone might reasonably conclude that this query should not be used in thesender intelligence scheme.

Another strategy for mitigating this risk is to weigh the validity ofsuspicious DNS queries against the IP reputations of the server that isperforming the lookup. In particular, the DNS resolvers associated withwell-known and reputable email inbox providers are less likely to beengaged in behaviors that obstruct legitimate operations or compromisesecurity of the queried domain.

Referring now to the figures and their accompanying description.Although modules (e.g., the enumerated software and/or hardware elementsillustrated in the figures, such as a DNS) are disclosed with specificfunctionality, it should be understood that functionality may be sharedbetween modules, with some functions split between modules, while otherfunctions duplicated by the modules. Furthermore, the name of the moduleshould not be construed as limiting upon the functionality of themodule. Moreover, each component disclosed within each module can beconsidered independently without the context of the other componentswithin the same module or different modules. Each component may containlanguage defined in other portions of this specification. Each componentdisclosed for one module may be mixed with the functionality of anothermodule. In the present disclosure, each component can be claimed on itsown and/or interchangeably with other components of other modules.

Referring now to the various figures depicting methods, flow charts, andoperational diagrams, along with their corresponding description(collectively referred to herein as “methods”). Such methods serve asexamples of one or more methods that may be performed by at least one ofthe aforementioned modules, or components thereof. Various hardwarecomponents may be used at the various stages of operations disclosedwith reference to each module. For example, although methods may bedescribed to be performed by a single computing device (e.g., a DNS), itshould be understood that, in some embodiments, different operations maybe performed by different networked elements in operative communicationwith the computing device. For example, at least one computing device1300 may be employed in the performance of some or all of the stagesdisclosed with regard to the methods. Similarly, an apparatus may beemployed in the performance of some or all of the stages of the methods.As such, the apparatus may comprise at least those architecturalcomponents as found in computing device 1300.

Furthermore, although the stages of the following example method aredisclosed in a particular order, it should be understood that the orderis disclosed for illustrative purposes only. Stages may be combined,separated, reordered, and various intermediary stages may exist.Accordingly, it should be understood that the various stages, in variousembodiments, may be performed in arrangements that differ from the onesclaimed below. Moreover, various stages may be added or removed withoutaltering or deterring from the fundamental scope of the depicted methodsand systems disclosed herein.

FIG. 1 illustrates an example of a block diagram of a messageauthorization data flow 100 in a SPF that includes DMARC. The message isgenerated by the mail user agent (MUA) 102 and sent to the mailsubmission agent (MSA) 104. The MSA 104 receives email messages from theMUA 102 and negotiates message delivery with a sending mail transferagent (sMTA) 106. The message may be forwarded by other MTAs 108 untilthe message is received by the receiving MTA (rMTA) 110. The message istransferred to the mail delivery agent (MDA) of the domain of theaddressee in the MDA filtering engine in block 112.

The message is sent to the DMARC verifier portion 116. An SPF verifierportion 118 has inputs extracted from the message headers. The SPFverifier portion 118 attempts to validate messages against the SPFpolicy published at the alleged sender's domain until, for example, amatch or error is found. The results of message validation could be amatch, non-match, or an exception.

Validation of the message is performed using the returned SPF policy andthe message header data. The DNS query for the DMARC policy of thesending domain is performed in block 120.

The results of the DNS query for sending the DMARC policy of the domainare returned to block 116. The results of the DMARC verifier 116 aresent to the MDA 112.

In block 114, the message is delivered to the user mailbox of a receiver(a user) following authentication and assertion in the published policy.In block 116, a DMARC report is generated and sent to a designated DMARCreport receiver in block 122, which may include, for example, a memorylocation or a terminal of a user.

FIGS. 2 and 3 illustrate a block diagram of an example embodiment of aflow of data sent by message volume (number of messages over time)monitoring system 200 having low-latency.

Referring to FIG. 2, the message is generated by the MUA 102 (of FIG. 2)and sent to the mail submission agent (MSA) 104. The MSA 104 receivesemail messages from the MUA 102 and negotiates message delivery with amail transfer agent (MTA) 106. The message may be forwarded by otherMTAs 108 until the message is received by the receiving MTA (rMTA) 110.The message is transferred to the MDA of the domain of the addressee inblock 112 and, subject to message verification checks, may be deliveredto the User Mailbox 114.

The message may be sent to the DMARC verifier portion 116. The verifierretrieves inputs extracted from the message headers. Validation of themessage is performed using the returned SPF policy and the messageheader data.

FIG. 3 illustrates a continuation of the diagram of FIG. 2. In thisregard, the SPF verifier 302 is called with desired inputs extractedfrom the message headers during the SPF query in block 302. The SPFquery may be any term or mechanism through which a macro may be used tocapture data and transmit data. Accordingly, during the SPF evaluationprocess, the macro-endowed term affects a query of the domain's DNS.

For example, in one embodiment, the “exists” term may be used. The“exists” is parsed into fields corresponding to those found in Table 1below by the field parser 306. In addition to the ‘exists’ mechanism,this could also be an ‘a’, ‘include’, etc. mechanism, or any SPF termthat is subject to macro expansion, may have the same effect.

In various embodiments, the macro terms of the employed SPF term mayobtain a username, an IP address, and other parameters of the message.Accordingly, the macro parameters, such as the username, the sendingdomain, and the sending internet protocol address (IP address) may beextracted in block 308. Header details are resolved in block 310. Inblock 312, the message source IP is compared to the list of IPs assertedin the SPF policy of the domain. If a match is found, the result of theSPF check is “pass”, which is returned to the receiving domain. If nomatch is found, the result of the check may be NXDOMAIN or one of theSPF qualifiers ‘fail’, ‘soft fail’, or ‘neutral’. In either case, i.e.,a “pass” or NXDOMAIN result, the data and the result are assembled inpreparation for writing into the data store.

Referring back to FIG. 2, data is written into the data store 204. Thedata store is accessible to the administrator application displayed tothe user on the user terminal 206. This gives fast access to the sendingvolume of individual users that can be presented to users using multipleuser interfaces.

Consistent with embodiment of the present disclosure, data processor 202may be employed to, for example, populate the data store. This may beperformed by, for example, the data processor accessing the DNS querylog and processing the queries contained therein. In some embodiments,for instance, the processing would be based on anchor characters usedto, for instance, identify the locations associated with data capturedfrom the macro sequences associated with the SPF policies correspondingto the queries. Such extracted data may then be provided to data store204, which may then be employed for displaying data or enabling actionsbased upon the data.

FIG. 4 illustrates a block diagram of an example method 400 forperforming the methods described above. In block 402, the DNS of theauthorizing domain is configured to log queries. Under the schemedescribed below, which are disclosed as examples for illustrativepurposes, the response of the query could be ‘NXDOMAIN’ or ‘Nameerror’[3, 8], meaning that the queried domain name does not exist in theDNS. Such a response may not be relevant to the sender volume resolutiondescribed here as the information to be extracted will be contained inthe actual query string.

In block 404, a tailored SPF policy is published. In order tobest-ensure that the sender will be counted, an SPF policy should haveas the first term an SPF mechanism or modifier with a macro charactersequence. As one non-limiting example, the ‘exists’ mechanism specifiesa domain name to use in a DNS A-record query during the SPFauthentication process. When combined with the special SPF macrocharacter sequences as described in RFC 7208, the name of the domain tobe queried can be constructed from a variety of message properties,including the email address of the sender, IP, and the HELO/EHLO domainof the outbound server.

As one non-limiting example, an ‘exists’ term published as part of anSPF policy published in a domain's DNS is:

exists:_i.%{i}._o.%{o}._d%{d}._%{1}._h.%{h}.example.com

A summary of the terms constituent to the ‘exists’ mechanism, usedherein as a non-limiting example, is provided in Table 1 with the macroterm and description of its expansion described respectively in thefirst two columns. The third column contains the corresponding termexpansions for the example where a user ‘joe@example.com’ sends an emailusing a google SMTP server with IP ‘209.XX.XXX.41”. Table 1 illustratesexamples of SPF macros used in the email sender intelligence.

TABLE 1 SPF macros used in an example email sender intelligence scheme.macro term description sample value %{i} IP address of the SMTP client209.XX.XXX.41 that is emitting the mail, either IPv4 or IPv6. %{o}domain of the “MAIL FROM” or example.com “HELO” identity %{d} domainthat provides the sought- example.com after authorization information;initially, the domain portion of the “MAIL FROM” or “HELO” identity.%{l} local-part of sender joe %{h} HELO/EHLO domain google.com

The full macro-substituted DNS name to be queried using this example isshown here:

_i.209.XX.XXX.41._o.example.com._d.example.com._l.joe._h.google.come.example.com

The information contained in this DNS name string may be saved. It maybe saved as, for example, the query field in the corresponding DNS querylog file when the SPF mechanism (i.e., ‘exists’ term) lookup isperformed during SPF authentication.

In block 406, information is extracted from DNS query logs. In thisexample, the corresponding DNS query has the form shown:

_i.209.XX.XXX.41._o.example.com._d.example.com._l.joe.h.google.com.example.com

Since the query may correspond to a non-existent domain, the result ofthis query could be, in such example, ‘NXDOMAIN’ as described earlier.The information about the sent email may be contained in the querystring itself as illustrated in Table 1. When this DNS query is made,the DNS logging system may record the information from the query into alog file.

One possible method to facilitate processing query information isdescribed, though other processing strategies are possible. It should beunderstood that the underscore-demarcation method described herein isonly one possible implementation that may be used to enable the spiritand scope of the embodiments disclosed herein. One of ordinary skill inthe field of the present disclosure may appreciate that it is not theonly implementation that may achieve the objective of certainembodiments. Accordingly, in some embodiments, preceding each of thefields is a unique string to demarcate each piece of information in thequery is one possible means for demarcating and/or extracting eachinformation field. For example, in the previous example, ‘_i.’(underscore, small-case letter I, and a period) precedes the IP addressfield and ‘_o.’ (underscore, small-case letter O, and a period) precedesthe ‘MAIL FROM’ identity field, etc. Engineering the query string inthis way facilitates reliable matching on the specially-chosen precedingcharacter strings so that individual fields can be extracted usingcommon string matching methodologies, e.g., regular expression matching.

As mentioned above, for each of the fields, the string matching logicmay be constructed as follows: 1. find label substring, e.g., . 2. matchsucceeding field, e.g., “209.XX.XXX.41” 3. stop matching at trailingperiod. This process may be performed until all field values areobtained. A timestamp may be added to the data harvested from the queryterm to facilitate time-resolution of each received message. Data fromthe DNS query logs may be accessible by administrator software fordisplaying the latest user sending-volume information. Alternatively, invarious embodiments, timed scripts, a.k.a., cron jobs, can be used toregularly pull this data from the logs into the data store; for example,a script to do this could be configured to run once per minute or onceper hour, depending on the time-resolution that is desired.

The data that allows tracking of user-resolved email sending volume mayalso be kept in a data store (memory) that may be separate from the DNSquery logs. In some embodiments, updates to this data should be pulledfrom the DNS query logs in an automated way, e.g., using timed scriptsor triggered by some other means. As an example, the data could bestored in a relational database with a table that, for example, maycontain fields such as those example fields illustrated in Table 1, and,in some embodiments, along with a query timestamp, IP of the resolverused, or any other metadata that may be present in the query that is ofinterest.

A user interface provides access to the data store. The user may usefilters or other means to access the desired data and desired metadata.FIG. 5 illustrates an example user interface 500 that has a first column502 that includes identifiers of a user or user account. The secondcolumn 504 illustrates a number of emails sent daily (i.e., over a giventime period) by each user.

FIG. 6 illustrates an example user interface 600 that includes a firstcolumn 602 that includes user names or account identifiers and a secondcolumn 604 that includes a number of messages sent over a period of time(e.g., weekly) by users. The user interfaces described herein may beimplicated by, for example, software that is operative to retrieve datafrom the data store 204 (of FIG. 2) and present the data to a user onthe user terminal 206. The software may, for example, verify and filterthe data to provide the desired information to the user such as, forexample, the email volume of an individual user or marketing accounts.

FIG. 7 illustrates an example of a block diagram of a messageauthentication data flow 700 in an SPF that includes DMARC. The messageis generated by the mail user agent (MUA) 702 and sent to the mailsubmission agent (MSA) 704. The MSA 704 sends the message to a DKIMsigner 705, which DKIM signs the message. The MSA 704 receives emailmessages from the MUA 702 and negotiates with message delivery with asending mail transfer agent (sMTA) 706. The message may be forwarded byother MTAs 708 until the message is received by the receiving MTA (rMTA)710. The message is transferred to the mail delivery agent (MDA) of thedomain of the addressee in the MDA filtering engine in block 712.

The message is sent to the DMARC verifier portion 716. An SPF verifierportion 718 has inputs extracted from the message headers. The SPFverifier portion 718 attempts to validate messages against the SPFpolicy published at the alleged sender's domain until, for example, amatch or error is found. The results of the SPF message validation couldbe a match, non-match, or an exception.

The DKIM verifier program may be called with needed inputs extractedfrom the message headers in block 720. In block 722, the DKIM verifierattempts to validate a message against sending the DNS-published publickey per specification in the message headers. The results of the DKIMvalidation are returned to the DMARC verifier 716, and the results ofthe SPF verifier 718 and DKIM validation are returned to DMARC verifier716.

The results of the DMARC verifier 716 are sent to the MDA 712 of therecipient. In block 714, the message is delivered to the User Mailbox ofa receiver (a user) following authentication and assertion in thepublished policy. In block 716, a DMARC report is generated and sent toa designated DMARC report receiver in block 724.

Validation of the message is performed using the returned SPF policy andthe message header data. The DNS query for the DMARC policy of thesending domain is performed in block 120.

FIGS. 8 and 9 illustrate a block diagram 800 of an example method forperforming authorization of email account holders to use external emailservice providers using message authentication domain name systemqueries.

The message is generated by the mail user agent (MUA) 802 and sent tothe mail submission agent (MSA) 804. The MSA 804 sends the message to aDKIM signer 805, which DKIM signs the message. The MSA 804 receivesemail messages from the MUA 802 and negotiates with message deliverywith a sending mail transfer agent (sMTA) 806. The message may beforwarded by other MTAs 808 until the message is received by thereceiving MTA (rMTA) 810. The message is transferred to the maildelivery agent (MDA) of the domain of the addressee in the MDA filteringengine in block 812. The message is sent to the DMARC verifier portion816.

During an SPF query, the macro endowed SPF term affects a DNS lookup ofthe domain in block 902. In block 904, the DKIM verifier program iscalled with needed inputs extracted from the message headers in block904. In block 904, the DKIM verifier attempts to validate a messageagainst sending the DNS-published public key per specification in themessage headers.

In block 908, the SPF term macro is parsed into fields such as thosedisclosed for illustrative purposes in Table 1. In block 910, detailsabout the sender are processed for authorization logic in the next stepand for log storage in block 912. Heretofore, a plurality of checks maybe performed. The checks may include, in no binding order, an IPauthorization check, a user restriction check, and a vendorauthorization check. Any one or more combinations of such checks may beperformed.

In block 916, the system determines if there are sending restrictionsassociated or assigned to the user, and that the user is attempting touse a vendor that has user permissions. In some embodiments, a priorcheck for IP authorization at block 914 may be performed.

If the user is not restricted from using specific vendors in block 916,the system validates the sending IP against existing SPF policy in block916. In some embodiments, an SPF evaluator function may return to theDNS server 906 a value corresponding to the results of vendor, IP, anduser verification checks. The DNS server 906 may respond accordingly tothe SPF verifier 902. If the user is not using a restricted vendor, theuser would not be restricted from processing an outbound message throughthe vendor. The user authorization is checked to determine whether theuser is authorized to use the vendor to send email.

In block 922, if the user is authorized to send a message using thevendor, then the DKIM public key specific to the vendor is published,and a ‘pass’ is returned to the SPF verifier. IF the user is notauthorized, the DKIM public key remains unpublished and a ‘fail’ isreturned to the SPF verifier 902.

The DKIM authentication subsequent to the dynamically published key willnow pass DKIM verification in block 904. The DKIM verifier 904 and SPFverifier 902 return a result to the DMARC verifier 816. Data is saved inthe data store 820 (of FIG. 8). The data is accessible to a user via anadministrator application, which provides fast access to individual usersending statistics. The data may be presented to the user on a userterminal 822 that is operative to display the data to the user andprovide a user interface for the user.

Consistent with embodiment of the present disclosure, data processor 818may be employed to, for example, populate the data store. This may beperformed by, for example, the data processor accessing the DNS querylog and processing the queries contained therein. In some embodiments,for instance, the processing would be based on anchor characters usedto, for instance, identify the locations associated with data capturedfrom the macro sequences associated with the SPF policies correspondingto the queries. Such extracted data may then be provided to data store820, which may then be employed for displaying data or enabling actionsbased upon the data.

FIG. 10 illustrates a flow diagram of a method 1000 for performingauthorization of email account holders. It should be noted that this isone example, of a plurality of examples, of how authorization may beperformed. In block 1002, the system configures individual userauthorizations on a per-vendor basis. A sample administrator userinterface for managing individual vendor authorizations is describedbelow and in FIG. 12. For example, the user is“shane.ireland@example.com” and the authorizations for each EXP in thelist can be toggled between on and off. For example, the user is allowedto send messages on behalf of the organization using Sendgrid, but notusing DocuSign, MailChimp, or Constant Contact. The individual userconfigurations are stored in a way that once a message authenticationrequest is made, a reply can be served in accordance with the vendorauthorized settings. An example of such a file 1100 is shown in FIG. 11.

Referring back to FIG. 10, in block 1004 the DNS of authorizing domainto log all queries includes access to the relevant DNS query logs. Datafrom the relevant DNS query logs will be used in the method toauthenticate vendor-sent messages according to the authorizations of theuser. In block 1006, the vendor DKIM public keys are managed by beingretained without publishing.

In block 1008, the tailored SPF policy is published. The SPF policyshould have as the first term an “exists” mechanism that specifies adomain name to use in a DNS A-record query during the SPF authenticationprocess. When combined with a special SPF macro character sequences asdescribed in RFC 7208, the name of the domain to be queried can beconstructed from a variety of message properties including, for example,an email address of the sender, IP, and the HELO/EHLO domain of theoutbound server.

As one non-limiting example, an example ‘exists’ term published as partof an SPF policy published in a domain DNS includes, for example:

exists:_i.%{i}._o.%{o}._d%{d}._%{l}._h.%{h}.example.com

A summary of the terms regarding the macro fields used in this exampleis shown above in Table 1.

Information is extracted from the DNS query log in block 1010. Theinformation about the sent email is contained in the query string. Asindicative above, a DNS query has an example form of:

_i.209.XX.XXX.41._o.example.com._d.example.com._l.joe._h.google.come.example.com

When the DNS query is made the DNS logging system records the query intoa log file. One may implement various strategies for demarcating and/orextracting each information field. Such a strategy is exemplified hereusing underscore-letter-dot tags, e.g., ‘_i.’ that precede eachrespective macro field. Other techniques may be employed to accomplishthe same task, and may be employed by data processor 818.

Since the results of a query may correspond to a non-existent domain,without an intervening process to negotiate the authentication, theresult of this query could be ‘NXDOMAIN’. In such a case, or a casewhere the DNS server becomes unresponsive to the authentication query,the proposed short-circuiting of the authentication simply fails intonormal authentication channels.

The data is stored in block 1012 may be stored in a location that isseparate from the DNS query logs. In some embodiments, the data may bestored in, for example, data store 820. Updates to the data are pulledfrom the DNS query logs in an automated way such as, for example,scripts or other routines. If the DNS server is properly configured, thedata store may be updated upon each relevant entry into the DNS querylogs. Alternatively timed scripts may be used to update the logs.

Vendor authorization logic to reply to the message authenticationrequests is applied in block 1014. Once a vendor is identified by thesource IP, and the user account is extracted from the DNS query, thepermission for that user to send messages via that vendor are determinedfrom the configuration, e.g., by comparing entries in a configurationfile such as 1100 (of FIG. 11).

If the user is allowed to send through the vendor account, then thecorresponding DKIM public key of the vendor is published in the DNS ofthe domain with a short time to live (TTL) such as, for example, a TTLvalue of 120 corresponding to two minute catching. A passing SPFevaluation is returned to the SPF verifier 902 (of FIG. 9). The messagewill authenticate and be delivered to the MUA of the receiver when apassing SPF disposition and a successful DKIM signature check arereturned.

FIG. 11 illustrates an example of a configuration file 1100 that has auser column 1102, a vendor column 1104, and a permission column 1106.

If the user is allowed to send through a vendor account, then thecorresponding DKIM public key of the vendor is published in the DNS ofthe domain with a short time to live (TTL) catching and a passing SPFevaluation is returned to the SPF verifier. Upon returning a passing SPFdisposition and a successful DKIM signature check, the message willauthenticate and be delivered to the mail user agent of the receiver.

FIG. 12 illustrates an example user interface 1200 for managing vendoraccess by individual email users. In this regard, the usershane.ireland@example.com is authorized to use one of the four emailservice providers for the organization.

The example methods and systems disclosed herein provide for collectingemail sending volume for individual users using message authenticationdomain name system queries. Other examples provide for performing an insitu authorization of email account holders to use external emailservice providers using message authentication domain name systemqueries.

The various modules illustrated in the Figures, such as FIGS. 2-3 and8-9 may be performed by one or more computing devices, individually orin combination. The one or more computing devices may be a local deviceand/or hosted on a centralized server, such as, for example, a cloudcomputing service. Although the methods has been described to beperformed by various computing elements, it should be understood that,in some embodiments, different operations may be performed by differentnetworked elements in operative communication with computing device1300.

Embodiments of the present disclosure may comprise a system having amemory storage and a processing unit. The processing unit coupled to thememory storage, wherein the processing unit is configured to perform thestages of the various methods.

FIG. 13 is a block diagram of a system including computing device 1300.Consistent with an embodiment of the disclosure, the aforementionedmemory storage and processing unit may be implemented in a computingdevice, such as computing device 1300 of FIG. 13. Any suitablecombination of hardware, software, or firmware may be used to implementthe memory storage and processing unit. For example, the memory storageand processing unit may be implemented with computing device 1300 or anyof other computing devices 1318, in combination with computing device1300. The aforementioned system, device, and processors are examples andother systems, devices, and processors may comprise the aforementionedmemory storage and processing unit, consistent with embodiments of thedisclosure.

With reference to FIG. 13, a system consistent with an embodiment of thedisclosure may include a computing device, such as computing device1300. In a basic configuration, computing device 1300 may include atleast one processing unit 1302 and a system memory 1304. Depending onthe configuration and type of computing device, system memory 1304 maycomprise, but is not limited to, volatile (e.g. random access memory(RAM)), non-volatile (e.g. read-only memory (ROM)), flash memory, or anycombination. System memory 1304 may include operating system 1305, oneor more programming modules 1306, and may include a program data 1307.Operating system 1305, for example, may be suitable for controllingcomputing device 1300′s operation. In one embodiment, programmingmodules 1306 may include a UI module (e.g., terminal), a DNS module, anExtraction Module (e.g., Data Processor), and an authorization module.Furthermore, embodiments of the disclosure may be practiced inconjunction with a graphics library, other operating systems, or anyother application program and is not limited to any particularapplication or system. This basic configuration is illustrated in FIG.13 by those components within a dashed line 1308.

Computing device 1300 may have additional features or functionality. Forexample, computing device 1300 may also include additional data storagedevices (removable and/or non-removable) such as, for example, magneticdisks, optical disks, or tape. Such additional storage is illustrated inFIG. 13 by a removable storage 1309 and a non-removable storage 1310.Computer storage media may include volatile and nonvolatile, removableand non-removable media implemented in any method or technology forstorage of information, such as computer readable instructions, datastructures, program modules, or other data. System memory 1304,removable storage 1309, and non-removable storage 1310 are all computerstorage media examples (i.e., memory storage.) Computer storage mediamay include, but is not limited to, RAM, ROM, electrically erasableread-only memory (EEPROM), flash memory or other memory technology,CD-ROM, digital versatile disks (DVD) or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to storeinformation and which can be accessed by computing device 1300. Any suchcomputer storage media may be part of device 1300. Computing device 1300may also have input device(s) 1312 such as a keyboard, a mouse, a pen, asound input device, a touch input device, etc. Output device(s) 1314such as a display, speakers, a printer, etc. may also be included. Theaforementioned devices are examples and others may be used.

Computing device 1300 may also contain a communication connection 1316that may allow device 1300 to communicate with other computing devices1318, such as over a network in a distributed computing environment, forexample, an intranet or the Internet. Communication connection 1316 isone example of communication media. Communication media may typically beembodied by computer readable instructions, data structures, programmodules, or other data in a modulated data signal, such as a carrierwave or other transport mechanism, and includes any information deliverymedia. The term “modulated data signal” may describe a signal that hasone or more characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media may include wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, radiofrequency (RF), infrared, and other wireless media. The term computerreadable media as used herein may include both storage media andcommunication media.

As stated above, a number of program modules and data files may bestored in system memory 1304, including operating system 1305. Whileexecuting on processing unit 1302, programming modules 1306 (e.g.,application 1320) may perform processes including, for example, one ormore of method stages as described above. The aforementioned process isan example, and processing unit 1302 may perform other processes. Otherprogramming modules that may be used in accordance with embodiments ofthe present disclosure may include electronic mail and contactsapplications, word processing applications, spreadsheet applications,database applications, slide presentation applications, drawing orcomputer-aided application programs, etc.

Generally, consistent with embodiments of the disclosure, programmodules may include routines, programs, components, data structures, andother types of structures that may perform particular tasks or that mayimplement particular abstract data types. Moreover, embodiments of thedisclosure may be practiced with other computer system configurations,including hand-held devices, multiprocessor systems,microprocessor-based or programmable consumer electronics,minicomputers, mainframe computers, and the like. Embodiments of thedisclosure may also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules may be located in both local and remotememory storage devices.

Furthermore, embodiments of the disclosure may be practiced in anelectrical circuit comprising discrete electronic elements, packaged orintegrated electronic chips containing logic gates, a circuit utilizinga microprocessor, or on a single chip containing electronic elements ormicroprocessors. Embodiments of the disclosure may also be practicedusing other technologies capable of performing logical operations suchas, for example, AND, OR, and NOT, including but not limited tomechanical, optical, fluidic, and quantum technologies. In addition,embodiments of the disclosure may be practiced within a general purposecomputer or in any other circuits or systems.

Embodiments of the disclosure, for example, may be implemented as acomputer process (method), a computing system, or as an article ofmanufacture, such as a computer program product or computer readablemedia. The computer program product may be a computer storage mediareadable by a computer system and encoding a computer program ofinstructions for executing a computer process. The computer programproduct may also be a propagated signal on a carrier readable by acomputing system and encoding a computer program of instructions forexecuting a computer process. Accordingly, the present disclosure may beembodied in hardware and/or in software (including firmware, residentsoftware, micro-code, etc.). In other words, embodiments of the presentdisclosure may take the form of a computer program product on acomputer-usable or computer-readable storage medium havingcomputer-usable or computer-readable program code embodied in the mediumfor use by or in connection with an instruction execution system. Acomputer-usable or computer-readable medium may be any medium that cancontain, store, communicate, propagate, or transport the program for useby or in connection with the instruction execution system, apparatus, ordevice.

The computer-usable or computer-readable medium may be, for example butnot limited to, an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system, apparatus, device, or propagationmedium. More specific computer-readable medium examples (anon-exhaustive list), the computer-readable medium may include thefollowing: an electrical connection having one or more wires, a portablecomputer diskette, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM or Flashmemory), an optical fiber, and quantum computing elements. Note that thecomputer-usable or computer-readable medium could even be paper oranother suitable medium upon which the program is printed, as theprogram can be electronically captured, via, for instance, opticalscanning of the paper or other medium, then compiled, interpreted, orotherwise processed in a suitable manner, if necessary, and then storedin a computer memory.

A variety of terms are used herein that should be known to one ofordinary skill in the art.

Internet Protocol (IP)—the IP specifies how the transmission of datafrom sources to destinations is performed. In particular, theimplementation involves unique fixed-length addresses for the sendingsource and the receiving destination. The specifications about IPaddressing is given in RFC 791.

Domain Name System (DNS)—The DNS is a hierarchical and decentralizednaming system for computers, services, or other resources connected tothe Internet or a private network. There are many RFCs that cover DNSstandards, but RFC 1034 and RFC 1035 provide much information aboutconcepts and implementation.

Internet Message Format—the vocabulary associated with email accounts isintroduced for use in descriptions provided in subsequent sections. Thespecifications for these matters are covered in RFC 5322. The addressspecification for an email address is a string of characters constitutedof a ‘local-part’ and the ‘domain’ separated by the at-signcharacter(“@”, ASCII value 64).

For example, in the address ‘xyz@example.com’, the local-part is ‘xyz’and the domain is ‘example.com’.

The ‘from’ address that occurs in a received message is sometimesreferred to as the 5322. From address, as the specification is coveredin RFC 5322. One of the reasons that email authentication protocols havebeen developed is the ease by which such information can be forged,e.g., with the proper tools, the 5322. From address in a sent messagecan be set to any address a dishonest sender may desire. Part of theDMARC validation process considers the legitimacy of this 5322. Fromaddress.

Simple Mail Transfer Protocol (SMTP)—the schemes by which email messagesare transported from the sender to a receiver have many technicaldetails that are not relevant to the embodiments described here. Thecurrent specification for how electronic mail is transferred is providedin RFC 5321. While SMTP uses only a reliable ordered data stream channeland is independent of the particular transmission subsystem, messagesare typically transmitted using TCP connection which guarantees IPresolution of the source. Other transport methods are described in theAppendices of RFC 821.

Sender Policy Framework (SPF)—before an email is delivered to an emailinbox of an addressee, the corresponding Mail Delivery Agent (MDA)should take steps to authenticate the sender of the email. One of themost utilized authentication protocols is the Sender Policy Framework(SPF). A domain owner asserts a list of IP addresses authorized to sendemail on behalf of the domain by specifying them in an SPF policypublished as a TXT resource record in the DNS of the domain. The rulesand syntax for the SPF protocol are specified in RFC 7208.

The SPF authentication process systematically compares the IP of thesender with those published in the SPF policy of the domain. If a matchis found, the message passes this authentication check; otherwise,authentication fails. For the purposes of accounting for the amount ofemail being sent by individual users, the actual SPF pass- orfail-disposition of the message is not relevant. Instead, an SPF term inthe policy is specially-crafted with a substitutable macro charactersequence to affect a DNS query; this will, in turn, generate animmediately accessible DNS log entry containing the information neededto resolve information about the sending source.

DMARC is a protocol for asserting an organization's preferencesregarding delivery of messages that do not pass validation checks. DMARCfurther provides a framework for generating reports of theauthenticating disposition of messages that use the 5322. Fromaddress ofthe organization's domain. It is designed to give email domain ownersthe ability to protect their domain against email identityimpersonation, commonly known as email spoofing. The primary outcome ofimplementing strict DMARC enforcement is to protect a domain from beingused in business email compromise attacks, phishing emails, email scamsand other cyber threat activities.

There are two from addresses associated with a message: the RFC5321.MailFrom address and the RFC 5322. From address. SPF authenticationalone: validates a sender against the nominal 5321. MailFrom address,falls back to RFC 5321.HELO address when the 5321. MailFrom is missing,and provides no consistency check between 5321. MailFrom and 5322. Fromfrom addresses.

The following conditions constitute DMARC identifier alignment for therespective authentication methods: DKIM: domain specified with ‘d=’ tagmust match 5322.From address and SPF: the SPF-authenticated domain(5321.MailFrom or 5321.HELO) and the 5322.From domain must be inalignment, as defined in RFC 7489, e.g., the organizational domains mustbe identical.

There are many more nuances to the authentication process. The mainpoint here is that there is a difference between authentication solelybased on SPF alone and that based on DMARC verification via SPF. Theauthentication flow for DMARC with SPF is diagrammed in FIG. 1.

A typical DMARC report generated by a sending MDA includes aggregatedinformation about sender IP addresses, 5321.MailFrom domain, 5322.Fromdomain, and the results of individual policy-based messageauthentications, e.g., a SPF pass or fail, and the DMARC disposition ofeach message. Conventionally, DMARC reports are sent to the authorizedreceivers of the domain once in a fixed 24 hour time interval.Importantly, individual messages are not timestamped; only a singletimestamp for the report itself is present. In simple terms, with DMARCalone administrators will wait an entire day or more to get sendinginformation that does not include message timestamps or senderaddresses.

While the specification includes examples, the disclosure's scope isindicated by the following claims. Furthermore, while the specificationhas been described in language specific to structural features and/ormethodological acts, the claims are not limited to the features or actsdescribed above. Rather, the specific features and acts described aboveare disclosed as examples for embodiments of the disclosure.

Insofar as the description above and the accompanying drawing discloseany additional subject matter that is not within the scope of the claimsbelow, the disclosures are not dedicated to the public and the right tofile one or more applications to claims such additional disclosures isreserved.

The following disclose a first set of aspects of the present disclosure.The various first set of aspects are not to be construed as patentclaims unless the language of the aspect appears as a patent claim. Thefirst set of aspects describe various non-limiting embodiments of thepresent disclosure.

Aspect 1 A system comprising:

a. a memory storage; and

b. a processor in operative communication with the memory storage, theprocessing being configured to:

c. enable a configuration of individual user authorizations to allowoutbound messaging through a specification of one or more authorizedvendors;

d. from publication to the DNS at least one DKIM public key associatedwith the one or more authorized vendors;

e. a customized sender policy framework (SPF) policy to the DNS, thecustomized SPF policy comprising a macro-endowed mechanism for obtainingat least one of the following:

i. username,

ii. IP address, and

iii. domain;

f. a received SPF customized queries;

g. a log comprising the received SPF customized queries;

h. data from the received SPF customized queries, the extracted datahaving been populated by the macro mechanism associated with the SPFcustomized query;

i. the extracted data comprising at least one of the following: theusername, the IP address, and the domain, as extracted from eachreceived SPF customized query; and

j. whether an individual associated with the username is authorized toutilize a vendor associated with the domain;

k. upon a determination that the individual is authorized to utilize thevendor, a DKIM public associated with the vendor.

Aspect 2. A method comprising:

a. a configuration individual user authorizations for allowing outboundmessaging through a specification of one or more authorized vendors;

b. a customized sender policy framework (SPF) policy to the DNS, thecustomized SPF policy comprising a macro-endowed mechanism for obtainingat least one of the following:

i. username,

ii. IP address, and

iii. domain;

c. a received SPF customized queries;

d. a log comprising the received SPF customized queries;

e. data from the received SPF customized queries, the extracted datahaving been populated by the macro mechanism associated with the SPFcustomized query;

f. the extracted data comprising at least one of the following: theusername, the IP address, and the domain, as extracted from eachreceived SPF customized query; and

g. whether an individual associated with the username is authorized toutilize a vendor associated with the domain;

h. upon a determination that the individual is authorized to utilize thevendor, a function to authorize the outbound messaging, whereinperforming the function to authorize the outbound messaging comprisesinforming at least one function running a domain name system (DNS) sothat an appropriate qualifier can be returned to for SPF verification.

Aspect 3. A computer-readable medium comprising a set of instructionswhich when executed by a computer perform a method, the methodcomprising:

a. a configuration of individual user authorizations for allowingoutbound messaging through a specification of one or more authorizedvendors;

b. a customized sender policy framework (SPF) policy to the DNS, thecustomized SPF policy comprising a macro-endowed mechanism for obtainingat least one of the following:

i. username,

ii. IP address, and

iii. domain;

c. a received SPF customized queries;

d. a log comprising the received SPF customized queries;

e. data from the received SPF customized queries, the extracted datahaving been populated by the macro mechanism associated with the SPFcustomized query;

f. the extracted data comprising at least one of the following: theusername, the IP address, and the domain, as extracted from eachreceived SPF customized query; and

g. whether an individual associated with the username is authorized toutilize a vendor associated with the domain;

h. upon a determination that the individual is authorized to utilize thevendor, a function to authorize the outbound messaging. whereinperforming the function to authorize the outbound messaging comprisesproviding an affirmative response to an authentication request inaccordance with a corresponding messaging protocol utilized, at least inpart, to perform a message request.

Aspect 4. The method of Aspect 2, wherein the customized SPF policycomprises at least one of the following:

i. macro character sequences, and

ii. term is either a mechanism or a modifier, such as, but not limitedto, an ‘exists’ term, an ‘a’ term, an ‘mx’ term, an ‘include term, a‘redirect’ modifier that accepts macros, and any other mechanism that ismacro compatible.

Aspect 5. The method of Aspect 2, wherein the macro-endowed mechanismcomprises at least one macro term used as a sender mechanism foridentifying at least one of the following: a username, an IP addresses,and a domain.

Aspect 6. The method of Aspect 5, wherein particular macro sequences ofthe macro-endowed mechanism facilitate a capture of data from an emailbeing sent by a specific user.

Aspect 7. The method of Aspect 6, wherein saving the string comprisesprocessing the query log for the data captured by the macro-endowedmechanism.

Aspect 8. The method of Aspect 7, further comprising at least one of thefollowing:

a. extracting the captured data, and

b. the extracted data as a string.

Aspect 9. The method of Aspect 8, wherein extracting comprisesidentifying a demarcation within the query to determine a location ofthe data captured by the macro-endowed mechanism.

Aspect 10. The method of Aspect 8, wherein storing comprises providingauxiliary data associated with logged SPF queries, the auxiliary datacomprising a timestamp.

Aspect 11. The method of Aspect 2, further comprising displaying, via auser interface, an identifier associated with system user and a numberof emails sent by the user over a time period.

Aspect 12. The method of Aspect 2, wherein the displaying is based on aretrieval of data extracted from a DNS query log comprising aspectscaptured from the macro-endowed mechanism.

Aspect 13. The computer-readable medium of Aspect 3, wherein thecustomized SPF policy comprises at least one of the following:

i. a macro character sequences, and

ii. term is either a mechanism or a modifier, such as, but not limitedto, an ‘exists’ term, an ‘a’ term, an ‘mx’ term, an ‘include term, a‘redirect’ modifier that accepts macros, and any other mechanism that ismacro compatible.

Aspect 14. The computer-readable medium of Aspect 13, wherein themacro-endowed mechanism comprises at least one macro term used as asender mechanism for identifying at least one of the following: ausername, an IP addresses, and a domain.

Aspect 15. The computer-readable medium of Aspect 14, wherein particularmacro sequences of the macro-endowed mechanism facilitate a capture ofdata from an email being sent by a specific user.

Aspect 16. The computer-readable medium of Aspect 15, wherein saving thestring comprises processing the query log for the data captured by themacro-endowed mechanism.

Aspect 17. The computer-readable medium of Aspect 16, further comprisingat least one of the following:

a. the captured data, and

b. storing the extracted data as a string.

Aspect 18. The computer-readable medium of Aspect 17, wherein extractingcomprises identifying a demarcation within the query to determine alocation of the data captured by the macro-endowed mechanism.

Aspect 19. The computer-readable medium of Aspect 17, wherein storingcomprises providing auxiliary data associated with logged SPF queries,the auxiliary data comprising a timestamp.

Aspect 20. The computer-readable medium of Aspect 3, further comprisingdisplaying, via a user interface, an identifier associated with systemuser and a number of emails sent by the user over a time period.

The following disclose a second set of aspects of the presentdisclosure. The various second set of aspects are not to be construed aspatent claims unless the language of the aspect appears as a patentclaim. The second set of aspects describe various non-limitingembodiments of the present disclosure.

Aspect 1. A method comprising:

a. receiving a configuration for a domain name system (DNS) to log allqueries;

b. publishing a customized sender policy framework (SPF) policy to theDNS, the customized SPF policy comprising a macro-endowed mechanism forobtaining at least one of the following:

i. a username,

ii. an IP address, and

iii. a domain;

c. logging a plurality of received SPF customized queries;

d. accessing a log comprising the plurality of received SPF customizedqueries;

e. extracting data from each of the received SPF customized queries, thedata being populated by the macro mechanism associated with the SPFcustomized query;

f. populating a datastore with extracted data comprising at least one ofthe following: the username, the IP address, and the domain, asextracted from each received SPF customized query; and

g. providing, based on the extracted data, an indication of outboundemails sent from the domain.

Aspect 2. The method of claim 1, wherein the customized SPF policycomprises at least one of the following:

i. a macro character sequences, and

ii. a term is either a mechanism or a modifier, such as, but not limitedto, an ‘exists’ term, an ‘a’ term, an ‘mx’ term, an ‘include term, a‘redirect’ modifier that accepts macros, and any other mechanism that ismacro compatible.

Aspect 3. The method of claim 1, wherein the macro-endowed mechanismcomprises at least one macro term used as a sender mechanism foridentifying at least one of the following: a username, an IP addresses,and a domain.

Aspect 4. The method of claim 1, wherein particular macro sequences ofthe macro-endowed mechanism facilitate a capture of data from an emailbeing sent by a specific user.

Aspect 5. The method of claim 4, wherein saving the string comprisesprocessing the query log for the data captured by the macro-endowedmechanism.

Aspect 6. The method of claim 5, further comprising at least one of thefollowing:

a. extracting the captured data, and

b. storing the extracted data as a string.

Aspect 7. The method of claim 7, wherein extracting comprisesidentifying a demarcation within the query to determine a location ofthe data captured by the macro-endowed mechanism.

Aspect 8. The method of claim 6, wherein storing comprises providingauxiliary data associated with logged SPF queries, the auxiliary datacomprising a timestamp.

Aspect 9. The method of claim 1, further comprising displaying, via auser interface, an identifier associated with system user and a numberof emails sent by the user over a time period.

Aspect 10. The method of claim 9, wherein the displaying is based on aretrieval of data extracted from a DNS query log comprising aspectscaptured from the macro-endowed mechanism.

Aspect 11. A system for tracking messages, the system comprising:

i. a memory storage; and

ii. a processor in operative communication with the memory storage, theprocessing being operative to:

1. publish a customized sender policy framework (SPF) policy to the DNS,the customized SPF policy comprising a macro-endowed mechanism forobtaining at least one of the following:

2. a username,

3. an IP address, and

4. a domain;

a. log a plurality of received SPF customized queries;

b. access a log comprising the plurality of received SPF customizedqueries;

c. extract data from each of the received SPF customized queries, thedata being populated by the macro mechanism associated with the SPFcustomized query;

d. populate the memory with extracted data comprising at least one ofthe following: the username, the IP address, and the domain, asextracted from each received SPF customized query; and

e. organize a display of the extracted data, the display beingconfigured to provide an indication of outbound emails sent from thedomain.

Aspect 12. The system of claim 10, wherein macro-endowed mechanismincludes a term, an “exists” mechanism specifies a domain name to use ina DNS A-record query during the SPF authentication process.

Aspect 13. The system of claim 11, wherein the ‘exists’ term is a sendermechanism for identifying IP addresses that either are permitted or arenot permitted to use an email of a domain identity.

Aspect 14. The system of claim 11, wherein combining the ‘exists’mechanism with particular macro sequences facilitates accounting anemail being sent by a specific user.

Aspect 15. The system of claim 10, wherein the processor is furtheroperative to save a string corresponding to a DNS query log,

Aspect 16. The system of claim 15, wherein the processor is furtherconfigured to process the query log for the data captured by themacro-endowed mechanism.

Aspect 17. The system of claim 16, wherein the processor is furtherconfigured to:

i. extract the captured data.

Aspect 18. The system of claim 16, wherein the processor is furtherconfigured to:

i. extract the captured data, and

ii. store the extracted data as a string.

Aspect 19. The system of claim 18, wherein the processor is furtherconfigured to identify a demarcation within the query to determine alocation of the data captured by the macro-endowed mechanism.

Aspect 20. The system of claim 18, wherein the processor is furtherconfigured to append auxiliary data associated with logged SPF queries,the auxiliary data comprising a timestamp.

Aspect 21. The system of claim 10, wherein the processor is furtherprovided, via a user interface, an identifier associated with systemuser and a number of emails sent by the user over a time period.

Aspect 22. The method of claim 9, wherein the displaying is based on aretrieval of data extracted from a DNS query log comprising aspectscaptured from the macro-endowed mechanism.

Aspect 23. A computer-readable medium including instructions forperforming a method, the method executed by the instructions comprising:

a. publishing a customized sender policy framework (SPF) policy to theDNS, the customized SPF policy comprising a macro-endowed mechanism forobtaining at least one of the following:

i. a username,

ii. an IP address, and

iii. a domain;

b. logging a plurality of received SPF customized queries;

c. accessing a log comprising the plurality of received SPF customizedqueries;

d. extracting data from each of the received SPF customized queries, thedata being populated by the macro mechanism associated with the SPFcustomized query;

e. populating a datastore with extracted data comprising at least one ofthe following: the username, the IP address, and the domain, asextracted from each received SPF customized query; and

f. organizing a display of the extracted data, wherein organizing adisplay of the extracted data comprises providing an indication ofoutbound emails sent from the domain.

Aspect 24. The computer-readable medium of claim 23, wherein thecustomized SPF policy comprises at least one of the following:

i. a macro character sequences, and

ii. a term is either a mechanism or a modifier, such as, but not limitedto, an ‘exists’ term, an ‘a’ term, an ‘mx’ term, an ‘include term, a‘redirect’ modifier that accepts macros, and any other mechanism that ismacro compatible.

Aspect 25. The computer-readable medium of claim 23, wherein themacro-endowed mechanism comprises at least one macro term used as asender mechanism for identifying at least one of the following: ausername, an IP addresses, and a domain.

Aspect 26. The computer-readable medium of claim 23, wherein particularmacro sequences of the macro-endowed mechanism facilitate a capture ofdata from an email being sent by a specific user.

Aspect 27. The computer-readable medium of claim 26, wherein saving thestring comprises processing the query log for the data captured by themacro-endowed mechanism.

Aspect 28. The computer-readable medium of claim 26, further comprisingat least one of the following:

a. extracting the captured data, and

b. storing the extracted data as a string.

Aspect 29. The computer-readable medium of claim 28, wherein extractingcomprises identifying a demarcation within the query to determine alocation of the data captured by the macro-endowed mechanism.

Aspect 30. The computer-readable medium of claim 28, wherein storingcomprises providing auxiliary data associated with logged SPF queries,the auxiliary data comprising a timestamp.

The following is claimed:
 1. A method comprising: receiving aconfiguration for a domain name system (DNS) to log all queries;publishing a customized sender policy framework (SPF) policy to the DNS,the customized SPF policy comprising a macro-endowed mechanism forobtaining the following: a username, an IP address, and a domain,wherein at least one particular macro sequence of the macro-endowedmechanism facilitates a capture of data from an email being sent by aspecific user; logging a plurality of received SPF customized queries;accessing a log comprising the plurality of received SPF customizedqueries; extracting data from each of the received SPF customizedqueries, the data being populated by the macro-endowed mechanismassociated with the SPF customized query, wherein extracting comprisesidentifying a demarcation within each query to determine a location ofthe data captured by the macro-endowed mechanism; populating a datastorewith extracted data comprising the following: the username, the IPaddress, and the domain, as extracted from each received SPF customizedquery; and providing, based on the extracted data, an indication ofoutbound emails sent from the domain associated with the specific user.2. The method of claim 1, wherein the customized SPF policy comprises atleast one of the following: a macro character sequences, and a termcorresponding to at least one of the following: an ‘exists’ term, an ‘a’term, an ‘mx’ term, an ‘include’ term, a ‘redirect’ modifier thataccepts macros, and any other mechanism that is macro compatible.
 3. Themethod of claim 1, wherein the macro-endowed mechanism comprises atleast one macro term used as a sender mechanism for identifying at leastone of the following: the username, an IP addresses, and the domain. 4.The method of claim 1, further comprising saving a string based on, atleast in part, a processing a query log for the data captured by themacro-endowed mechanism.
 5. The method of claim 4, further comprising atleast one of the following: extracting the captured data, and storingthe extracted data as the string.
 6. The method of claim 5, whereinstoring comprises providing auxiliary data associated with logged SPFqueries, the auxiliary data comprising a timestamp.
 7. The method ofclaim 1, further comprising displaying, via a user interface, anidentifier associated with system user and a number of emails sent by auser over a time period.
 8. The method of claim 7, wherein thedisplaying is based on a retrieval of data extracted from a DNS querylog comprising aspects captured from the macro-endowed mechanism.
 9. Asystem for tracking messages, the system comprising: a memory storage;and a processor in operative communication with the memory storage, theprocessing being operative to: publish a customized sender policyframework (SPF) policy to the DNS, the customized SPF policy comprisinga macro-endowed mechanism for obtaining the following: a username, an IPaddress, and a domain, wherein at least one particular macro sequence ofthe macro-endowed mechanism facilitates a capture of data from an emailbeing sent by a specific user; log a plurality of received SPFcustomized queries, access a log comprising the plurality of receivedSPF customized queries, extract data from each of the received SPFcustomized queries, the data being populated by the macro-endowedmechanism associated with the SPF customized query, wherein extractingcomprises identifying a demarcation within each query to determine alocation of the data captured by the macro-endowed mechanism, populatethe memory with extracted data comprising the following: the username,the IP address, and the domain, as extracted from each received SPFcustomized query, and organize a display of the extracted data, thedisplay being configured to provide an indication of outbound emailssent from the domain associated with the specific user.
 10. The systemof claim 9, wherein the macro-endowed mechanism includes an ‘exists’term that specifies a domain name to use in a DNS A-record query duringan SPF authentication process.
 11. The system of claim 9, wherein the‘exists’ term is a sender mechanism for identifying IP addresses thateither are permitted or are not permitted to use an email of a domainidentity.
 12. The system of claim 9, wherein combining the ‘exists’mechanism with particular macro sequences facilitates accounting theemail being sent by the specific user.
 13. The system of claim 9,wherein the processor is further operative to save a stringcorresponding to a DNS query log.
 14. The system of claim 13, whereinthe processor is further configured to process a query log for the datacaptured by the macro-endowed mechanism.
 15. The system of claim 14,wherein the processor is further configured to: extract the captureddata.
 16. The system of claim 14, wherein the processor is furtherconfigured to: store the extracted data as the string.
 17. The system ofclaim 16, wherein the processor is further configured to appendauxiliary data associated with logged SPF queries, the auxiliary datacomprising a timestamp.
 18. The system of claim 9, wherein the processoris further provided, via a user interface, an identifier associated withsystem user and a number of emails sent by a user over a time period.19. The method system of claim 9, wherein the processing beingconfigured to organize the display displaying is based on a retrieval ofdata extracted from a DNS query log comprising aspects captured from themacro-endowed mechanism.
 20. A non-transitory computer-readable mediumincluding instructions for performing a method, the method executed bythe instructions comprising: publishing a customized sender policyframework (SPF) policy to the DNS, the customized SPF policy comprisinga macro-endowed mechanism for obtaining the following: a username, an IPaddress, and a domain, wherein at least one particular macro sequence ofthe macro-endowed mechanism facilitates a capture of data from an emailbeing sent by a specific user; logging a plurality of received SPFcustomized queries; accessing a log comprising the plurality of receivedSPF customized queries; extracting data from each of the received SPFcustomized queries, the data being populated by the macro-endowedmechanism associated with the SPF customized query, wherein extractingcomprises identifying a demarcation within each query to determine alocation of the data captured by the macro-endowed mechanism; populatinga datastore with extracted data comprising the following: the username,the IP address, and the domain, as extracted from each received SPFcustomized query; and organizing a display of the extracted data,wherein organizing the display of the extracted data comprises providingan indication of outbound emails sent from the domain associated withthe specific user.
 21. The non-transitory computer-readable medium ofclaim 20, wherein the customized SPF policy comprises at least one ofthe following: macro character sequences, and a term corresponding to atleast one of the following: an ‘exists’ term, an ‘a’ term, an ‘mx’ term,an ‘include’ term, a ‘redirect’ modifier that accepts macros, and anyother mechanism that is macro compatible.
 22. The non-transitorycomputer-readable medium of claim 20, wherein the macro-endowedmechanism comprises at least one macro term used as a sender mechanismfor identifying at least one of the following: the username, an IPaddresses, and the domain.
 23. The non-transitory computer-readablemedium of claim 20, further comprising saving a string based on, atleast in part, a query log for the data captured by the macro-endowedmechanism.
 24. The non-transitory computer-readable medium of claim 20,further comprising at least one of the following: extracting thecaptured data, and storing the extracted data as a string.
 25. Thenon-transitory computer-readable medium of claim 24, wherein storingcomprises providing auxiliary data associated with logged SPF queries,the auxiliary data comprising a timestamp.